home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1599 / 1469 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.4 KB
  1. Date: Thu, 26 May 1994 08:05:32 +0200
  2. From: Christian Lynbech <lynbech@daimi.aau.dk>
  3. Message-Id: <199405260605.AA20385@avignon.daimi.aau.dk>
  4. To: warwick@cs.uq.oz.au
  5. In-Reply-To: <9405260005.AA29735@uqcspe.cs.uq.oz.au> (message from Warwick Allison on Thu, 26 May 1994 10:05:37 +1000)
  6. Subject: Re: GEMDOS re-entrancy
  7. Comments: Hyperbole mail buttons accepted, v3.12P.
  8.  
  9.  
  10. >>>>> "Warwick" == Warwick Allison <warwick@cs.uq.oz.au> writes:
  11.  
  12. Warwick> ekl@sdf.lonestar.org (Evan K. Langlois):
  13. >>  Question, why AES and VDI?  Well, they are the same trap for one.
  14. >> And I thought the calls were executed in supervisor mode so that
  15. >> they couldn't be re-entered anyway.  And isn't the VDI re-entrant?
  16. >> Hmm .. maybe not since you can't call the AES from a G_USERDEF
  17. >> object.
  18.  
  19.  
  20. Warwick> WHICH VDI?  NVDI and Nova VDI spring to mind, and the
  21. Warwick> Cybercube boards' VDI.
  22.  
  23. Warwick> To me, the question really is, why would you want AES and VDI
  24. Warwick> to be reentrant?
  25.  
  26. Warwick> X11 doesn't draw anything in parallel.
  27.  
  28. There is one snag, when talking about GEM (that is AES and VDI). If
  29. GEM is not reentrant, one process should block GEM while executing a
  30. GEM function. That is no problem for graphics, it takes the time it
  31. takes anyway, but dont forget the event loop. The typical GEM program
  32. will call an event_something and block GEM for a very long time!
  33.  
  34. Reentrancy is one solution, another would be to have some server
  35. thingy, such that GEM thinks there is only two GEM programs in the
  36. system (I remember having seen that AES is reentrant to three levels),
  37. one of which never calls event_anything. Then clients (!) could send
  38. request to the server which would use GEM messages to forward it to a
  39. dispatcher process, which would otherwise be suspended in GEM waiting
  40. for the union of all requested events (plus the server messages of
  41. course), shipping back events to the server whenever one occurred.
  42.  
  43. A pretty complicated alternative to MultiAES, but should be a workable
  44. solution. One could even start enhancing things as all calls goes
  45. through a server, adding things like X style keyboard handling,
  46. network support etc.
  47.  
  48.  
  49.  
  50. ------------------------------------------------------------------------------
  51. Christian Lynbech               | Hit the philistines three times over the 
  52. office: R0.33 (phone: 3217)    | head with the Elisp reference manual.
  53. email: lynbech@daimi.aau.dk    |        - petonic@hal.com (Michael A. Petonic)
  54. ------------------------------------------------------------------------------
  55.